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Abstract 


This standard outlines a smart contract interface eligible to represent any number of 
fractionalized non-fungible tokens. Existing projects utilizing standards like EIP-1633 
conventionally deploy separate EIP-20 compatible token contracts to fractionalize the 
non-fungible token into EIP-20 tokens. In contrast, this ERC allows each token ID to 
represent a token type representing(fractionalizing) the non-fungible token. 


This standard is approximate in terms of using _id for distinguishing token types. 
However, this ERC has a clear difference with EIP-1155 as each _id represents a 
distinct NFT. 


Motivation 


The conventional fractionalization process of fractionalizing a NFT to FT requires 
deployment of a FT token contract representing the ownership of NFT. This leads to 
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inefficient bytecode usage on Ethereum Blockchain and limits functionalities since 
each token contract is separated into its own permissioned address. With the rise of 


multiple NFT projects needing to fractionalize NFT to FT, new type of token standard 
is needed to back up them. 


Specification 


/ ** 
@title Multi-Fractional Non-Fungible Token Standard 
@dev Note : The ERC-165 identifier for this interface is @x83f5d35f. 


*/ 
interface IMFNFT { 
JEF 
@dev This emits when ownership of any token changes by any mechanism. 
The `_from` argument MUST be the address of an account/contract sending the 
The `_to` argument MUST be the address of an account/contract receiving the 
The `_id` argument MUST be the token type being transferred. (represents NFI 
The ~_value~ argument MUST be the number of tokens the holder balance is dec 
ei 


event Transfer(address indexed _from, address indexed _to, uint256 indexed _id, 


JEF 
@dev This emits when the approved address for token is changed or reaffirmec 
The `_owner` argument MUST be the address of account/contract approving to n 
The `_spender` argument MUST be the address of account/contract approved to 
The `_id` argument MUST be the token type being transferred. (represents NFI 
The `_vaLue` argument MUST be the number of tokens the `_approved` is able t 
*/ 


event Approval(address indexed _owner, address indexed _spender, uint256 indexec 


/** 
@dev This emits when new token type is added which represents the share of t 
The `_parentToken` argument MUST be the address of the Non-FungibLle Token cc 
The ~_parentTokenId~ argument MUST be the token ID of the Non-FungibLle Toker 
The ~_td~ argument MUST be the token type being added. (represents NFT) 
The ~_totalSupply~ argument MUST be the number of total token supply of the 
oe 


event TokenAddition(address indexed _parentToken, uint256 indexed _parentTokenIc 


JEF 
@notice Transfers `_vaLue` amount of an `_id` from the msg.sender address tc 
@dev msg.sender must have sufficient balance to handle the tokens being trar 
MUST revert if `_to` is the zero address. 
MUST revert if balance of msg.sender for token ~_id is Lower than the `_val 
MUST revert on any other error. 
MUST emit the “Transfer” event to reflect the balance change. 
@param _to Source address 
@param _id ID of the token type 
@param _value Transfer amount 
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@return True if transfer was successful, false if not 


function transfer(address _to, uint256 _id, uint256 value) external returns (bc 


JEF 


y 


@notice Approves `_vaLue` amount of an `_id` from the msg.sender to the `_st 
@dev msg.sender must have sufficient balance to handle the tokens when the ` 
MUST revert if `_spender` is the zero address. 

MUST revert on any other error. 

MUST emit the `Approval` event. 

@param _spender Spender address(account/contract which can withdraw token or 
@param _id ID of the token type 

@param _value Approval amount 

@return True if approval was successful, false if not 


function approve(address _spender, uint256 (id, uint256 value) external returns 


JEF 


wá 


@notice Transfers `_vaLue` amount of an `_id` from the ~_from address to tt 
@dev Caller must be approved to manage the tokens being transferred out of t 
MUST revert if `_to` is the zero address. 

MUST revert if balance of holder for token `_id is Lower than the ~_value™ 
MUST revert on any other error. 

MUST emit ~Transfer~ event to reflect the balance change. 


@param _from Source address 
@param _to Target Address 
@param _id ID of the token type 


@param _value Transfer amount 
@return True if transfer was successful, false if not 


function transferFrom(address _from, address _to, uint256 _id, uint256 value) «€ 


SEF 


a 


@notice Sets the NFT as a new type token 

@dev The contract itself should verify if the ownership of NFT is belongs tc 
MUST revert if the same NFT is already registered. 

MUST revert if ~_parentNFTContractAddress is address zero. 

MUST revert if ~_parentNFTContractAddress» is not ERC-721 compatible. 
MUST revert if this contract itself is not the owner of the NFT. 
MUST revert on any other error. 

MUST emit ~TokenAddition™ event to reflect the token type addition. 
@param _parentNFTContractAddress NFT contract address 

@param _parentNFTTokenId NFT tokenID 

@param _totalSuppLy Total token supply 


function setParentNFT(address _parentNFTContractAddress, uint256 _parentNFTToker 


JEF 
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@notice Get the token ID's total token supply. 
@param _id ID of the token 
@return The total token supply of the specified token type 
i 
function totalSupply(uint256 _id) external view returns (uint256); 


JEF 

@notice Get the balance of an account's tokens. 

@param _owner The address of the token holder 

@param _id ID of the token 

@return The _owner's balance of the token type requested 
*/ 


function balanceOf(address _owner, uint256 _id) external view returns (uint256) ; 


SEF 
@notice Get the amount which `_spender` is still allowed to withdraw from ` 
@param _owner The address of the token holder 
@param _spender The address approved to withdraw token on behalf of `_owner` 
@param _id ID of the token 
@return The amount which ~_spender” is still allowed to withdraw frc 
3 


function allowance(address _owner, address _spender, uint256 _id) external view 


SEF 
@notice Get the bool value which represents whether the NFT is already regis 
@param _parentNFTContractAddress NFT contract address 
@param _parentNFTTokenId NFT tokenID 
@return The bool value representing the whether 
*/ 
function isRegistered(address _parentNFTContractAddress, uint256 _parentNFTToker 
} 
interface ERC165 { 
JEF 
@notice Query if a contract implements an interface 
@param interfaceID The interface identifier, as specified in ERC-165 
@dev Interface identification is specified in ERC-165. This function 
uses Less than 30,0@@ gas. 
@return “true” if the contract impLements ~interfaceID™ and 
“interfaceID is not Oxffffffff, “false otherwise 
*/ 


function supportsInterface(bytes4 interfaceID) external view returns (bool); 


To receive Non-Fungible Token on safe Transfer the contract should include 
onERC721Received() . Including onERC721Received() is needed to be compatible with 
Safe Transfer Rules. 
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JEF 
@notice Handle the receipt of an NFT 
@param _operator The address which called `safeTransferFrom` function 
@param _from The address which previously owned the token 
@param _tokenId The NFT identifier which is being transferred 
@param _data Additional data with no specified format 
@return ~bytes4(keccak256("onERC721Received(address, address, uint256, bytes)"))~ 


i 
function onERC721Received(address _operator, address _from, uint256 _tokenId, bytes 
d 
Rationale 
Metadata 


The symbol() & name() functions were not included since the majority of users can 
just fetch it from the originating NFT contract. Also, copying the name & symbol 
every time when token gets added might place a lot of redundant bytecode on the 
Ethereum blockchain. However, according to the need and design of the project it 
could also be added to each token type by fetching the metadata from the NFT 
contract. 


Design 


Most of the decisions made around the design of this ERC were done to keep it as 
flexible for diverse token design & architecture. These minimum requirement for this 
standard allows for each project to determine their own system for minting, 
governing, burning their MFNFT tokens depending on their programmable 
architecture. 


Backwards Compatibility 


To make this standard compatible with existing standards, this standard event & 
function names are identical with ERC-20 token standard with some more events & 
functions to add token type dynamically. 


Also, the sequence of parameter in use of _id for distinguishing token types in 
functions and events are very much similar to ERC-1155 Multi-Token Standard. 


Since this standard is intended to interact with the EIP-721 Non-Fungible Token 
Standard, it is kept purposefully agnostic to extensions beyond the standard in order 
to allow specific projects to design their own token usage and scenario. 


Test Cases 


Reference Implementation of MFNFT Token includes test cases written using hardhat. 
(Test coverage : 100%) 
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Reference Implementation 
MFNFT - Implementation 


Security Considerations 


To fractionalize an already minted NFT, it is evident that ownership of NFT should be 
given to token contracts before fractionalization. In the case of fractionalizing NFT, 
the token contract should thoroughly verify the ownership of NFT before 
fractionalizing it to prevent tokens from being a separate tokens with the NFT. 


If an arbitrary account has the right to call setParentnFT() there might be a front- 
running issue. The caller of setParentnFT() might be different from the real NFT 
sender. To prevent this issue, implementors should just allow admin to call, or 
fractionalize and receive NFT in an atomic transaction similar to flash loan(swap). 
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